WORLD INTELLECTUAL PROPERTY ORGANIZATION 
[memational Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) international Patent Classification 6 : 
C06V 17/60 



Al 



(ID International Publication Number 
(43) International Publication Date: 



WO 98/16893 

23 April 1998 (23.04.98) 



(21) International Application Number: PCT/US97/IX675 

(22) International Filing Hate: ! 4 October IW ( I 4. 10.97) 



(JO) Priority Data: 

60/028.397 
OH/950. J 28 



I 5 October 1996 (15.10.96) 
! 4 October 1997 (14.10.97) 



US 
US 



(71) Applicant: CYMEDIX CORP. [US/US]; Suite 117. 100 East 

Thousand Oaks Boulevard, Thousand Oaks, CA 9 1360 (US). 

(72) Inventors: BERMAN, Keith; 1623 Elmsford Street, Westtake 

Village. CA 91361 (US). MISHAIL, Sima;- 22036 Collins 
Street #227. Woodland Hills. CA 91367 (US). TAPPIN, 
William; 30K56 Agoura Road CI 2, Agoura Hills. CA 91 301 
(US). ASBELL Barbara; 2043 Sunndge Drive, Ventura, 
CA 93003 (US). NGUYEN. Tom, V.. 22300 Sattcoy Street, 
Canoga Park, CA 91303 (US). 

(74) Agents: PATRICK. Steven. C. et al.; Koppel & Jacobs, Suite 
302, 31255 Cedar Valley Drive, Westlake Village. CA 
91362 (US). 



(81) Designated States: AL, AM. AT. AU, AZ. BA. BB. BG, BR 
BY. CA, CH, CN, CU, CZ, DE, DK, EE. ES. HI, GB. GF.' 
HU. IL. IS, JP, KE, KG. KP. KR. KZ. LC, LK. LR. LS. LT. 
LU. LV. MD. MG, MK. MN, MW. MX. NO. NZ, PL, PI\ 
RO. RU. SD, SE, SG. SI, SK, TJ. TM. TR. TT. UA, \JG. 
UZ, VN, ARIPO patent (GH. KE, LS, MW. SD, SZ. UG. 
ZW), Eurasian patent (AM, AZ, BY, KG. KZ, MD, RU, TJ. 
TM). European patent (AT, BE, CH, DE, DK. ES, FI, FR, 
GB, GR. IE, IT. LU. MC. NL, PT, SE), OAPI patent (BF." 
BJ, CF. CG. CI, CM, GA, GN. ML, MR. NE. SN, TD. TG). 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 



(54) Title: AUTOMATED NETWORKED SERVICE REQUEST AND FULFILLMENT SYSTEM AND METHOD 




(57) Abstract 

An automated networked service request and fulfillment system and method includes "client" computer systems (10, 30, 32, 34, 36) 
in the offices of professionals such as doctor;, and "sponsor" computers (12, 38. 40. 42) at the sites of service providers such as test labs or 
insurance companies, interconnected with a mail server system (14) that exchanges e-mail messages via the Internet or a similar network 
(16). "Service requests", such as ordering a medical test or requesting authorization for a particular procedure, are prepared using a client 
system and automatically e-mailed to the sponsor system of an appropriate service provider. Tne request is fulfilled and the results e-mailed 
buck to the requesting client system using the mail server system. Confidentiality is insured by encrypting all e-mail messages. The system 
includes a "universal interface" component (290) which automates the process of converting data records found in existing databases into 
the data record formal required by the new system. 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


n 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AC 


Australia 


GA 


Gabon 


LV 


trivia 


sz 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TO 


Chad 


BA 


Doima and Herzegovina 


CK 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


Gil 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BC 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


It 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


' Bc!arui 


IS 


Iceland 


MW 


Malawi 


US 


United Slates oi America 


CA 


Canada 


IT 


Italy 


MX 


Me* ico 


uz 


Uzbekistan 


<:f 


Central African Republic 


JP 


Japan 


NE 


N.ger 


VN 


Viet Nam 


cc 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CI I 


Switzerland 


KG 


Kyrgyutan 


NO 


Norway 


zw 


Zimbabwe 


CI 


Cote cj'lvoire 


KP 


Democratic People * 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KK 


Republic of Korea 


FT 


Portugal 






cu 


Cuba 


KZ 


Kazakstan 


RO 


Romania 






cz 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






UK 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






1>K 


Denmark 


LK 


Sn Lanka 


SE 


Sweden 






£E 


Ksionia 


LR 


Liberia 


SC 


Singapore 







WO 98/16893 



1 



PCT/US97/18675 



AUTOMATED NETWORKED SERVICE REQUEST AND FULFILLMENT 
SYSTEM AND METHOD 

This application is a continuation-in-part of Provisional 
Application No. 60/023,397, filed October 15, 1996. 

BACKGROUND Of THE INVENTION 

fie id of the Invent ion 

This invention relates to - the field of automated 
service request and fulfillment systems, particularly 
systems in which requests are made and fulfilled over a 
computer network. 

Description of th e Related Art 

The health care industry and its endlessly spiraling 
costs are subjects of great concern at present, with new 
methods of - managing medically-related information 
introduced regularly. A labor intensive approach has 
traditionally been taken to manage such information: a 
doctor orders a medical procedure on a multi-ply form, 
and a copy is delivered to a medical center Dy the 
patient, a courier, or via facsimile or mail. The 
results are returned to the doctor in similar fashion, 
recorded on paperwork which is physically carried back to 
the ordering doctor's office. Verifying a patient's 
medical insurance status traditionally requires that 
personnel working in a doctor's office or health care 
facility consult the latest revision of an insurer's 
printed "eligibility" list, or attempt to learn the 
status via telephone. 

In the "managed health care" operating environment 
favored by health maintenance organizations (HMOs J, 
member doctors typically must request and receive 
"authorization" from a patient's HMO prior to performing 
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a particular medical procedure. The request for 

authorization, and its subsequent approval or denial, are 
commonly handled with an exchange of paperwork, via the 
nails. Similarly, permission to refer a patient to 
ar.otner doctor is usually requested and received via 
mailed or hand-delivered paperwork. 

Many modern offices have attempted to improve their 
efficiency by introducing computers. A myriad of 

"complete medical office management" software products 
are in use which keep track of patient information and 
medical histories, billing and insurance information, 
etc. These products generally place such information 
into "data records'' which are stored in one or more 
databases within a personal computer. The "format" of 
the information in a data record, i.e., the precise 
arrangement of text, data, and control characters whicn 
make up the record, is unique to most of the products in 
the market, as is the way in which the data records are 
arranged into a database. When an office adopts a new 
management system, a transfer of the stored information 
from the existing database to a new database is 
necessitated. However, because of the differences in the 
data record and database formats of the old and new 
products, such a transfer is typically accomplished by 
manually re-entering data into the new database one 
record at a time. 

• Some offices have linked their computer systems to 
various insurance providers via costly, proprietary 
computer networks, for purposes of determining insurance 
eligibility, for example. However, as with the office 
management software products, most of the existing 
network systems are unique, with each system having its 
own set of system requirements, operating procedures, and 
communications protocols. Confidentiality is also a 
serious concern when using a network, and while some 
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network-based systems do encrypt the data sent over tne 
network, the quality of the various encryption schemes 
and the procedures associated with them tend to vary 
widely. Also, : many of these networks are arranged so 
that tneir user interface screens must be downloaded into 
the office computer over the network, which often results 
in long delays and poor responsiveness for the user due 
to the large amount of data that must be transferred over 
the network. 

Similar problems and attempted solutions are found 
in other professional fields. For example, a brokerage 
may store investor identification and portfolio 
information in a database of some sort. The brokerage 
may need to communicate with a variety of off-site 
service providers, such as financial exchanges, quotation 
services, etc. As in the medical field, many software 
products and proprietary networks have been introduced to 
improve the management of financial information, but the 
vast technical differences which exist between competing 
products tends to also provide a host of incompatibility, 
upgrading and training problems. 

SUMMARY OF THE INVENTION 

A system and a method are presented for making and 
fulfilling service requests between two or more remote 
sites over the Internet or a similar computer network, 
which overcome many of the problems noted above. 

The novel system uses a client-server electronic 
mail (e-mail) architecture. A "client-' computer system 
is located in the office of a professional such as a 
doctor, a "sponsor'' (server) computer system is located 
at the site of a service provider, such as a testing lab, 
hospital, or insurance company, and a network-based mail 
server system serves as an interface between the two. 

A client makes "service requests" by entering 
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mrormation on an appropriate request screen generated 
^ P ' e Cllsnt system's display by resident software 
TV?iCal Service -^quests might include the ordering of 
cxood test for a particular patient, a request to 
authorization to perform a particular medical procedure 
or a request for a quotation on a particular fmancia 
investment, product. The client system f ormaCs a 

completed service request into a "service reauesr 
message", which is e-mailed to the sponsor system G f" a 
service provider capable of providing the requested 
service using the mail server system. The sponsor system 
monitors its mailbox for service request messages, 
retrieves those found, and submits them to the service 
provider for processing. 

The service provider processes the service request 
message and the results are formatted into a "fulfilled 
service request" message, which the sponsor system e- 
■-naiis back to the requesting client using the mail server 
system. The client system monitors its mailbox for 
fulfilled service request messages, retrieves those 
found, and presents them to the requestor on demand. 

A complete system per the present invention 
typically includes hundreds of client systems and dozens 
of. sponsor systems, with every system able to communicate 
with every other system via the Internet. For example, 
client systems might be located in the respective offices 
of all the member doctors of an HMO, with sponsor systems 
located at a number of facilities which provide various 
services to the HMO. 

To insure the confidentiality of sensitive data, 
both the service request and the fulfilled service 
request messages are preferably encrypted. Further 
privacy is achieved by separating each encrypted message 
into two messages: a "public" data message, which might 
include patient identification information, and a 
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,p:iVaCe " ^ mess ^'. containing the results of the 
-agent's blood test, for example. 

-he mail server system 

y m can be any network-based 
^" e:n intended to enable the e\ch*nn& 

excnan 9 e of e-mail messages 

L "'" vee: ' computers at remote sit^s An o ma • i 

An e-mail provide- 
operating on the Internet i s , n • 

. ^rnec is a primary example; a 

-crporatxon's proprietary intranet between facil^s <- 
another. v ■ * ^ 

The present system requires that a database of 

in ' 0tMti0n ' SUCh 35 the ^entities of a roster of 
paints, be built up on the client system Many 

P ;°- eSSi ° nal ° ffiC6S haVS -""ng databases containing 
this information. The invention deludes a "universal 
interface- software component which automates the process 
o- converting this information from its existing form 
into the format required by the new system. 

Further features and advantages of the invention 
wi- be apparent to those skilled xn the art from ■ th- 
-ollowing detailed description, taken together with the" 
accompanying drawings. 

FIG. 1 is a block diagram of an automated servxee 
'st and fulfillment system per the present invention 
rlG- 2 is a flow diagram of the steps performed by a 
cient system to prepare a service request message. 

FIG. 3 is a flow diagram of the steps performed by a 
client system to send outgoing and retrieve incoming e- 
mail messages. 

FIG. 4 is a flow diagram of the steps performed by a 
client system to process retrieved e-mail messages. 

FIG. 5 is a flow diagram of the steps performed by a 
sponsor system to send outgoing and retrieve incoming e - 

mail messages. 

FIG. 6 is a flow diagram of the steps performed by a 
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universal interface component of the present invention to 
convert legacy database information into the data record 
rormat used by a client system. 

5 ^TArr.Eo QE-srqTPT T n N 0F the [NVf:WTTnM 

An automated networked service request and 
fulfillment system is - shown in FIG . 1. The 3ysterp 
includes a client system 10, a sponsor system 12, and a 
mail server system 14 which employs a computer network 
10 16. Service requests are made by entering data into a 
screen displayed on the client system, which formats the 
entered data into "service request messages" which are 
electronically mailed re-mailed") to a sponsor system or 
another client system v ia the computer network. The 
recipient of the service request message processes the 
request, formats the results into a "fulfilled service 
request message", and e-mails the fulfilled service 
request message back to the client system that made the 
request . 

0 The client system 10 is preferably a personal 

computer (PC) which includes a display device 20 such as 
a CRT or laptop screen, data entry devices 22 such as a 
mouse and keyboard, and a directly accessible "local" 
aata storage medium 24, such as a hard disc drive. 
Client system 10 uses the "WINDOWS" operating system, 
version 3.1 or greater, or Windows NT, version 3.5 or 
greater, made by Microsoft Corp. of Redmond, Washington. 
The client system also includes a network communication 
interface 26, such as a conventional modem. 

The present invention includes software 28 stored on 
data storage medium 24. Client system 10 executes the 
instructions making up software 28 to enable a user to 
create and send service request messages to other, off- 
site computers such as sponsor system 12, and to receive 
fulfilled service request messages back from those off- 
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sice systems. Software 28 is referred to herein as the 
"client software". 

The invention is particularly well-suited for use in 
tr.e health care industry. In this context, the client 
system 10 is typically in a doctor's office, and soonso^ 
system 12 is, for example, at an insurance company, 
testing lab, or hospital. The kinds of service requests 
that might be prepared and e-mailed by personnel m the 
doctor's office include: an order for a specific blood 
> test to be performed at a specific testing lab for a 
specific patient; a request that a particular medical 
procedure or referral be authorized by a particular 
insurance company for a particular patient; a request 
that a patient be admitted to a local hospital; a request 
tnat the eligibility of an individual patient for 
insurance coverage be verified. For these examoles, a 
sponsor system 12 is located at the site of each' of the 
service providers: at the testing lab, the insurance 
company, and the hospital. Upon receiving a service 
request message from client system 10, the service 
provider performs the requested service: the testing lab 
performs the requested blood test and produces the test 
results, the insurance company decides whether or not to 
provide authorization for a procedure or referral or 
looks up a patient's eligibility, or the hospital ore- 
admits the patient pending his arrival. 

The service provider processes the service request 
by performing the requested service, and the results of 
the processing, consisting m the above examples of the 
test results, the authorization decision or eligibility 
status, or the pre-admission confirmation, are received 
by the sponsor system and formatted into a fulfilled 
service request message which is e-mailed back to the 
original requestor. 

Though designed and implemented with the health care 
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" d ' J ; ti:y in mind ' Che invention is not Unuted to , hls 
A SysCem 35 P r «ented herein, witn wnicn a clienc 



S " CeCeiVe SPSClf - - rviC es from remote 

, :"7"- rS ° Ver a C ° mpUter — k ' also finds use, for 

- —Pie. in the financial industry or legal field A 

h T C ° Uid emPl - * — -h 
" al eXChangS 3nd/ - station service as se-v^ 
Providers. Reauests to buy or sell a certain securit^ 
tne exchange, or for the current price of a particular 
0 -st,, product . could be made a 

-th a system as herein described, with a resul 

reaction confirmation or price Rotation returned to 
the requestor < over the network. Similarly, a legaI 
Practitioner might order service Qf ^ 

particular individual by a process-serving service, or 
arrange for a court stenographer to be present at a 
certain time and place, with request and 
messages sent over a computer network. 

^ .A practical automated networked service request and 
-l.rll.ent system per the present invention i ncludes 
-ny perhaps hundreds or thousands, of client systems 

U 38 ' n 3 SmaUer nUmb6r ° f SP °— S >^s 

l\ 4 °' 311 -d sponsor systems 

—d by computer network 16. Each client and sponsor 
system linked to network 16 is able to send 
request messages and receive fulfilled service request 
messages from any other system similarly linked 

Mail server system 14 is typically provided by a 
commercial internet provider which offers e-mail 
services, such as America Online. However, mail server 
system 14 can also be a system that controls a corporate 
intranet. As i mpleme nted, the invention exchanges 
service req Uest messages and fuifiUed 

messages which have been formatted, a, " standard Simple 
.Mail Transfer Protocol (SMTP) e-mail messages, and the 
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server system preferably follow, this standard , 

ZZZ eonc * ,t 15 Ialid for other — ' 

I *»*««•» « implanted would r»qu< 

r ; diffareat mau — ^««« ». «« o 

-P-y=d, the w . t4il system requlres rha = 

:r sy ; teras used b ' °« — =u.„ t „d s " PO ;:; 

haracterrstic is fou „ d ^ J 

internet s.mce provider,: because the providers „. Z 
connected together via the mternet. an e . MU — 
«n ce sent by an originator and received by an addressee 
even lt they subscribe to different Internet provider's 

The client systenv 10 is connected to the mail serv-r 
system 14 usrng communication lines 46, which could be 
- entronal phone lines or dedicated high-speed data 

I ' SXamPle - ™« systems network 

communication interface 26 must be compatible with the 
type of anes 46 used, and the mail server system must 

em?1 ° V a " int «"« 48 =■■-". °f nandlinc the data 
-onveyed over lines 46. Once received by the mail server 
sys.em ,4, e-mail me ssages are conveyed to thei. 
addressee via computer network 16. 

A service request is initiated by executing the 
instructions making up client software 28. which as 
noted above, is stored on directly accessible data 
storage medium 24. Requiring the client software 28 to 
be directly accessible to the client system eliminates 
the slow response problems inherent in network systems 
»hic„ must transmit most or all of their user interface 
over the network. 

Once client software 28 is executed, a user mav 
select from a number G f different service request 
screens, each designed to prorr.pt the user to provide the 
mrormatxon necessary to carry out the specific request 
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The e- Mii addresses of the sponsor systems ' to which ~ach 

reqUeSt 15 t0 be SenC Preferably previously 

" re ° a databa " °n data storage medium 24. 

Once a service request screen is se ; oc , ed 



-tions found m client software 28 carry 



out the 



sequence of steps shown in the flow diagram of' rr G 2 

" US " SeieCtS 3 SCreen in SCe P 100, which i5 dismayed 
on a display device 20 in step 102. The selected screen 

tyP1CaUy lnClUdSS bl3nk lines *»* spaces into which da^a 
- to be entered with data entry devices 22 (step 10 4> 
For example, ' the screen might dlSDlay 
NAME : « Piay 

_ , and the user is 'to type in the 

appropriate name. Other data ma „ k 

" aaCa ma y be entered with a 
mouse, bv selecting a particular entry in a 2 
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Clicking on it, for example. The user is not permitted 
to continue until all necessary data has been entered 

. WMCh 13 CSSCed ^ StSP 106 - " ^ -quired data" has 
oeen entered, the entries are read by the software at 

step 108, and a hard copy of the service 

Lne service request is 
automatically printed out at step 110. 

At step Hi, che completed service request is 
preferably saved into a file which the user is prompted 
to specify. By saving the service requests, a user may 

« T ° Ptl0n ' thS Service "quest at any time in 

" tne future. 

The software 28 converts the service request into a 
service request e-mail message at step 112, formatting 
the message as required by the network over which th~ 
message is to be sent. At the present ^ ^ 

messages sent over the Internet must be in standard SMTP 
format . 



30 



m addition to the SMTP message format, the content 
of the e-mail messages exchanged across the system 
whether sent by a client or a sponsor system, preferably 
- adhere to a particular format as well. The Bessage 



been 
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concent standard with which the present system has 
implemented is the "HEALTH LEVEL 7- standard develooed ov 
Health Level 7 Corp. ^of Ann Arbor, Michigan. This 
standard, specifically designed for the exchange of 
> .-ne.icaiiy sensitive information over a computer network 
does the following to a service request or fulfilled 
service request message sent over a computer network- l, 
splits the message into two e-mail messages: a "public- 
data message, which might include patient identification 
0 -.formation, for example, and a "private" data message " 
containing the results of the patient's blood test for 
example; 2) encrypts both private and pub i ic messages 
using the Pretty Good Privacy ( PGP) encryption scheme 
-men is publicly available on the Internet, using 
aifferent private and public keys for the two messages; 
and 3) compresses the messages. The Health Level 7 
standard also decompresses, decrypts and reasserts 
messages which have been received by the prope- 
addressee. it is not essential that the presen^ 
invention be implemented with this standard, but some 
means of security should be employed to insure the 
confidentiality of the information conveyed over the 
network . 

Thus, at step 112, the service request message is 
preferably converted into a public message and a private 
message, both of which are encrytped, compressed, and 
formatted in compliance with the SMTP message format. 

The formatted messages are placed into an outgoing 
client mailbox 114 (identified in FIG. 1) at step 116 
which consists of an area of the client system's iocai 
data storage 24 designated for this purpose. 

Referring back to FIG. 1, electronic mailboxes are 
established in the various mail server systems 14, 44 
utilized by the clients and sponsors. Electronic "remote 
sponsor mailboxes" 120 are maintained by the nail server 
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system, co which the service request messages m outcome 
client mailbox 114 are sent (as described below). ' Each 
or the remote sponsor mailboxes 120 is associated with a 
:ive service provider. Because outgoing servic- 
messages are divided into separate private and 
puolic messages, remote sponsor mailbox 120 is divided 
into two sections: a private data mailbox 120a and a 
public data mailbox 120b, with each section having ' iCs 
own e-mail address. 

10 A "remote client mailbox" 122 is also maintained by 

the mail server system, to which fulfilled service 
request messages are sent (as described below,. Remote 
client mailbox 122 is also preferably divided into , 
private data mailnox 122a and a public data mailbox 122b, 
5 each with its own e-mail address. 

The client system 10 also includes an incomma 
client mailbox 128, into which fulfilled service reauest 
messages are put when retrieved from remote cHenr 
n-ailbox 1 22 . The cilGnt SQftware 28 controlg 

transfer of e-mail messages out of and into the outgoing 
and incoming mailboxes 114 and 128, respectively, wit* 
the process steps used to control these transfers shown 
xn the flow diagram of FIG. 3. 

The presence of a message to be sent in outgoing 
client mailbox 114 is detected in one of two ways. m 
step 150, a user-settable timer is monitored to see 
whether it has timed-out. Alternatively, a check of 
mailbox 114 can be initiated by the user, as shown in 
step 152. if either event has occurred, the outgoing 
client mailbox 114 is checked for messages at step 154. 

If a message is found in step 154, the message is 
sent to the e-mail address associated with the 
appropriate remote sponsor mailbox at step 156. The e _ 
mail addresses of all sponsors in the system are 
typically in a database stored on data storage medium 24, 
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and Che software 28 automatically retrieves and attaches 
the app ropriate address tQ the outgQlng service 

nessage based; on the type of request being made. 

After all outgoing messages have been e-mailed, the 
=> remote client mailbox- 122 xs checked for fulfilled 
service request messages at step 158. if any are found 
the private data message ^ pubiic ^ m 

components of each fulfilled service request are 
retrieved at step 160. 

10 The private and public data messages are decrypted 

at step 162, decompressed at step 163, and then 
reassembled into a fulfilled service request message and 
written to incoming client mailbox 128 at step 164 The 
program flow then returns to step 150. The continuously- 
looping sequence shown in FIG . 3 preferably runs in the 
background. 

In practice, a typical time-out period at step 150 
would be about 30 minutes, to insure that newly-created 
service request messages are promptly sen t and that 
fulfilled service request" messages recently sent by a 
sponsor system are promptly retrieved. 

Fulfilled service request messages written to 
incoming client mailbox 128 are processed in accordance 
with the steps shown in the flow diagram of FIG. 4. The 
incoming client mailbox is checked for fulfilled service 
request messages when a time-out period, preferably about 
30 seconds, expires, as shown in steps 200 and 202. 

As the system is implemented, a fulfilled service 
request message found in the incoming client mailbox 
takes one of two forms: it can either be received in 
response to a service request message previously e-mailed 
from the client system, or it can be sent by a sponsor 
system as a "database update". Database updates are sent 
by service providers such as insurance companies, to 
update information such as price schedules, doctor 
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rererral rosters, or diagnosis rosters. stored ir. 
databases on the client system. A message adhering to 
Health Level 7 format distinguishes between these two 
message types based on the message's "header". At step 
— 3, client software 28 determines which type of message 
is present. 

If client software 28 determines that the message is 
a fulfilled service request message, an attempt is made 
at step 204 to match the fulfilled request with the 
service -requests saved at step 111 of FIG. 2. If a match 
is found, the fulfilled service request message i S 
automatically printed at step 206. If not, the fulfilled 
service request message is written to a temporary file 
and the user notified (at step 208). The program flow 
then returns to step 200. 

If client software 28 determines that the message is 
a database update, processing continues at step 210, 
where the update information is written into the proper 
database on the client system, and program flow then 
returns to step 200. The continuously-looping sequence 
snown in FIG. 4 preferably runs in the background. 

Referring back to FIG. 1, sponsor systems 12, 38, 
40, 42 also use the "WINDOWS" operating system, version 
3-1 or greater, or Windows NT version 3.5 or greater. 
The sponsor systems each include a directly accessible 
data storage medium 220 and a network communication 
interface 222. The primary function of the sponsor 
systems is to retrieve service request messages sent to 
them from any of client systems 10, 30, 32, 34, 35 and to 
e-mail fulfilled service request messages back to the 
requesting client systems. Software 224 residing on 
storage medium 220 controls the receiving and sending of 
the requests, and is referred herein as the "sponsor 
software". 

The sponsor system 12 will usually be connected to a 
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"legacy system" 226. The i 0 „„ 

- ThS le 3acy system tyoicaiiy 

" d " 1SgaCy =°™ication interface- 228 w-'ch 
" ;n " h ^ C ° nneCtS t0 3 Sp ° ns °- s ^em 12. When a L 
_ -a sponsor system are configured in this way, che 

"T !, ? r SyStem 12 lnCiUdSS 3 "^or communication 
- c. .30. Da , a i S bidirectionally exchanged 

oetween the two systems 

Ulelr respective 

communication interfaces 228 and 230. 

The legacy system 226 is typically the comout^ 

system a service provider has traditionally used prior to 
Procuring the present invention. The service provider's 
Personnel interact with the legacy system, Wlth c , e 
sponsor system generally operating automatically and 

without intervention. Service reou^r m 

rvice request messages received 
oy the sponsor system are automatically transferred to 
the legacy system for processing by the service provider 
Tne necessary work is performed: a patient's blood tes^ 
xs run, a decision is made regarding the authorization of 
a requested medical procedure, etc., and the results of 
tne work are entered into the legacy system. The sponsor 
system 12 automatically retrieves results from the legacy 
si-tern 226, assembles a fulfilled service req u es t 
message, and e-mails the fulfilled service request 
message back to the requesting client system 10. 

It is not essential that the legacy system 226 and 
sponsor system 12 be. separate systems: a single system of 
sufficient processing and storage capacity could serve as 
both systems, with the capacities needed dependent on the 
amount of incoming service request messages. However 
oecause a service provider's legacy system is genera Uy 
not designed to handle a high volume of Internet e-mail, 
a separate sponsor system is recommended. 

The sponsor system 12 must submit service request 
messages to and receive results from a legacy system 226 
Because different legacy systems handle these data 



0 
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exchanges differently, sponsor software 224 mu -. 

;; JSt ° mi2ed f ° r the P^trcular legacy system 226 'being 
USsd °y a particular service provider. 

The sequence of instructions followed by soonsor 
'"■" 3r " 224 13 shown in ^ - f ±°" diagram of FIG . 5 The 
sponsor system connects to the mail server system via its 
network communication interface 222 at step 250. if 
results have been received from the legacy system (st-p 
252), or if any database updates are to be sent, the" a- 
formatted into fulfilled service request messages at'st-p 
254. if the preferred Health Level 7 formatting ' is use d 
the fulfilled service request is divided into encrypted 
ana compressed private and public data messages. At St - D 
256, the private and public messages are e-mailed to the 
private and public sections, respectively, Q f the 
appropriate remote client mailboxes. 

The system next proceeds to step 258, or jumos r Q 
step 258 directly if there were no results available at 
step 252, where the remote sponsor mailbox is checked f 0 r 
service request messages. If there are, the requests are 
retrieved into the sponsor system at step 260, and then 
deleted from the mail server system at step 262. The 
sponsor system is disconnected from the mail server 
system at step 264. 

At step 266, service request messages retrieved at 
step 260 are processed and submitted to the legacy 
system. The sequence then cycles back to step 250. 

The automated networked service request and 
fulfillment system described herein also includes a 
"universal interface" software component 290, typically 
stored on the client system's data storage medium 24 
(identified in FIG. 1), which provides a solution to the 
problems encountered as a result of the myriad of 
database record formats presently m use m professional 
offices. In the past, converting these existing, 
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"iec 
forma: 



egacy" database records into the record and database 
rrr.at used by a new office management software packaoe 
required hours of manual data re-entering. The universal 
lnt5:raCe Pr°g«m provides an automated method of 
: " r;r " :n7 the iegac ^ daCa records, converting them into 
J" 1 ' rSC ° rd f ° maC USed and neede d by the client software 
2o. and scoring the converted records into a new 
aataoase. This process normally need only be performed 
once, wnen the automated networked service request ana ■ 
tulfillment system is first incorporated into an offic- 
Once all the legacy records have been converted and 
stored into a new database, all new records are entered 
directly into the new database. 

A flow diagram of the steps performed by the 
universal interface software is shown in FIG. 6 To 
transfer the data records stored in a first format m a 
legacy database into data records stored in the format 
and database used oy client software 28, a user first 
executes the application program associated with the 
legacy database at step 300. Although there are many- 
different database application programs in use, which use 
-any different formats, one function common to nearly all 
such database programs is the ability to print out 
reports, such as a patient roster or a list of insurance 
providers. As a means of accessing a group of legacy 
data records, the user selects one of these resorts to be 
printed at step 302. At step 304, the software 290 
causes the report, which includes the database records to 
be transferred, to be written to a file rather than 
printed. 

At step 306, the universal interface software 290 is 
executed on the system to which the legacy databas'e 
records are to be transferred, which is typically the 
client system 10. At step 308, the file written at step 
304 is retrieved by che software 290 and the contents 
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displayed on display device 20. As displayed, the fil 
^ Ukeiy tQ inc ^e a header and a footer, with a nur.be 
°f data records between the header and footer. Each data 
record r ypicaily lncludes printer control characters ^ 
craca laoels and delimiters. Each record will ais ' 0 
include -daca fields", which contain information such as 
a patient's name, ID number, birth date, sex, etc. it 
the data fields from each data record m the fi ie which 
are to be transferred into the new database. 
10 At step 310, the user indicates the beginning of the 

first record to be transferred and the end of the last 
record to be transferred, using the mouse, for example, 
to define for software 290 the area in which the data of 
interest is confined. 
5 At step 312, the user selects a data field to 

convert from within a selected data record, preferably 
the first data field of the first data record, and 
indicates the " beginning and end of the selected field. 
As implemented, this is done by "highlighting" the data 
field by dragging the mouse cursor across it. At step 
314. the contents of the highlighted field are 
identified. A list of possible identifiers is presented, 
including labels such as "Patient ID", "Name", "Date Of 
Birth", and "Sex", and the user selects the entry on the 
list that describes the highlighted field. 

Now that the selected data field's text has been 
highlighted and identified with a particular label, 
software 290 converts the highlighted field into the 
database format used by client software 28 at step 316, 
which can be any of a number of user-determined formats 
including the Health Level 7 database format. The 
converted data field is displayed for review at step 318, 
to verify that the field was correctly converted. 

At step 320, software 290 "maps" the location of the 
data field just converted, by noting its position in 
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r * U - 0n = ° ^ beginning of the selected record, and tre 
^' dracte " which Precede and follow the field, f or 



ex ir.cie. 



there are ,ore data fields Co be converted in the 
- ^ = ^d record, the software 290 branches (at steo 32V 
o .i c k to step 312 and another data fxeid is highlighted' 
Steos 312, 314, 316, 319 and 320 are repeated unci' aH 
tne data fields of interest m the selected record hav- 
oeen converted, displayed, reviewed and mapped. if th-re 
are data fields in the selected record which are not 
needed in the new database, they are simply ignored 
during this sequence of steps. 

When all data fields of interest m the selected" 
record have been processed as discussed above, the 
program flow moves to step 324. Here, the software 290 
automatically converts the data fields of interest in all 
the remaining data records in the file to the formac 
required by the client software database. The start and 
end of the data records m the file were defined at step 
310, and the description and location of each data field 
within a record were identified and mapped at steps 314 
and 320, respectively. This information is used by 
software 290 to properly locate and convert the data 
fields of interest in each of the remaining data records, 
without user intervention. At step 326, the converted 
data fields from each of the file's data records are 
stored into the database used by client software 28. 

The file created at step 304 may contain hundreds or 
thousands of data records. Because all but one record 
are converted automatically, a significant time and cost 
savings results from using the universal interface 
software 290 to establish the new database needed by 
client software 28. 

The sequence of steps shown in FIG . 6 is repeated 

tor each of the legacy database reports which contain 
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data needed by client software 28. The legacy database's 
"patient: roster" and "insurance providers" reports are 
Cne -P°- s ai°st typically run through the universal 

in "err ace for conversion. 

i The universal interface software 290 can be used 

effectively with virtually any iegacy database . Beca , Jse 
the user defines the location of the data fields for th- 
software 290, the method works regardless of the 
particular spacing and delimiters employed by the legacy 
10 database. 

Client software 28, sponsor software 224, and 
universal interface software 290 are not limited to any 
particular programming language or software product. As 
presently implemented, Microsoft's "Visual C++" is use d 
for ail program logic, and Sybase's "SQL Anywhere" is 
used to provide both client and sponsor databases. 
Microsoft Corp. is m Redmond, Washington, and Sybase 
Corp. is in Emeryville, California. 

While particular embodiments of the invention have 
20 been shown and described, numerous variations and 
alternate embodiments will occur to those skilled in the 
art. Accordingly, it is intended that the invention be 
limited only in terms of the appended claims. 
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An automated service request and fulfillment 
-'-■L use over a computer network, comprising: 



client system (10) which includes a di 3pld -, 



y 



device (20), a data entry device (22), a data storag. 
medn:n (24) and a network communication interface (26;, 
said client system programmed to: 

retrieve a service request screen stored 
on said data storage medium and display said screen on 
said display device, 

accept data entered onto said service 
request screen with said data entry device and generate a 
service request message which includes said data, 

electronically mail (e-mail) said service 
request message through said client system' s network 
communication interface and over a computer network (16) 
to a remote sponsor mailbox (120), and 

retrieve fulfilled service request 
messages from a remote client mailbox (122) over a 
computer network and through said client system's network 
communication interface, and 

a sponsor system (12) which includes a network 
communication interface (222), said sponsor system 
programmed to: 

retrieve service request messages from 
said remote sponsor mailbox over a computer network and 
through said sponsor system's network communication 
interface , 

receive the results of processed service 
request messages and format them into fulfilled service 
request messages, and 

■e-mail said fulfilled service request 
messages through said sponsor system's network 
communication interface and over a computer network to 



WO 98/16893 

PCT7US97/18675 

22 

said rexote client mailbox. 

The 3 >' s tem of claim 1, further comprising a 
'" V: -- s -" veJr system (H) correctable to said client 
system, said sponsor system and to a computer network, 
said mail server system arranged to maintain said remote 
client and sponsor mailboxes and to transfer messages 
oetween said mailboxes via said network. 

3. The system of ' claim i, wherein said sponsor 
system encrypts and compresses a fulfilled service 
request message when e-mailed to said remote client 
mailbox and said client system decrypts and decompresses 
said fulfilled service request message when retrieved 
from said remote client mailbox. 

4. The system of claim 1, wherein said remote 
client mailbox includes a public data mailbox (122b) and 
a private data mailbox (122a), said sponsor system 
divides a fulfilled service request message into public 

nd private e-mail messages, and separately e-mails said 
and private e-mail messages into said public and 
private data mailboxes, respectively, over said computer 
network . 



5. The system of claim 1, further comprising a 
legacy system (226) which is connectable to said sponsor 
system and programmed to receive a service request 
message from said sponsor system and to provide data to 
said sponsor system to be included in a fulfilled service 
request message. 



a 

oub 1; 



6. The system of claim 1, further comprising a 
computer network (16) connectable to said client and 
sponsor systems and arranged to convey service request 
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messages ar.d fulfilled service request messages between 
" id rern ° te Client ^^box and said remote sponsor 



o c. 



1-3 l.CCX , 



<- The system of claim 1, wherein said sponsor 
system is further programmed to e-mail database updates 
and said client system is further programmed to receive 
said updates and zo modify databases stored on said 
client system data storage medium to reflect said 
updates. 

8. The system of ciaim i, further comprising a 
plurality of additional client systems (30,32,34,36) and 
a plurality of additional sponsor systems (38,40,42), 
arranged such that each of said client and sponsor 
systems can send e-mail messages to and receive e-mail 
messages from every other client and sponsor system. 

9. An automated service request system for use 
over a computer network, comprising: 

a client system (10) which includes a display 
device (20), a data entry device (22), a data storage 
medium (24) and a network communication interface (26), 
said client system programmed to: 

retrieve a service request screen stored 
on said data storage medium and display said screen on 
said display device, 

accept data entered onto said service 
request screen with said data entry device and generate a 
service request message which includes said data, 

electronically mail (e-mail) said service 
request message through said client system's network 
communication interface and over a computer network (16) 
to a remote sponsor mailbox (120) which is associated 
with a service provider capable of fulfilling said 
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retrieve tul tilled service request 



^ r -' m a remote client mailbox (122) over 



--work and throuqh said client system's network 
-•Oir:r_;:i -cation interface. 

10. A method of transferring data records which are 
r ° r " fKtGd in d first record format and stored in a 

first dataoase, to a second database with each 
transferred data record formatted in a second data record, 
format, each of said data records having a plurality of 
data rields, comprising the steps of: 

selecting a group of data records from said 
first database to be transferred to said second dataoase 



o; 



writing said group of data records to a file 
stored on a data storage medium (304), 

retrieving and displaying said file from said 
data storage medium (308), 

indicating the beginning and end of a selected 
data field in a selected data record (312), 

converting the indicated data in said selected 
data tie lei to said second record format (316), 

mapping the location of the selected data field 
within said selected record (320), 

repeating the steps of indicating the beginning 
and end of a selected data field in a selected record, 
converting the data m said selected data field to said 
second record format, and mapping the location of the 
selected data field within said selected record, for all 
25 :he otner data fields in said selected record which are 
to be transferred, 

automatically converting the data records 
remaining in said group to said second record format 
using said data field mapping data (324), and 
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storing said records converted into said second 
" fJ ° r '- : rorrriat: into said second database (326) . 
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